-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix scrolling with SetConsoleWindowInfo #16334
Fix scrolling with SetConsoleWindowInfo #16334
Conversation
@@ -217,7 +217,7 @@ void Renderer::TriggerSystemRedraw(const til::rect* const prcDirtyClient) | |||
// - <none> | |||
void Renderer::TriggerRedraw(const Viewport& region) | |||
{ | |||
auto view = _viewport; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HAH. But then, shouldn't we get rid of the entire cached viewport? We're just kicking the "torn state" can down the road...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the past scrolling was entirely implicit in the renderer as it computed the scroll and its invalidation just from the previous and current viewport. Nowadays we also got explicit scrolling, presumably for ConPTY edit: it was added with v2. Unfortunately (and similar to other parts here), the old code never got removed/unified and so we need to retain the behavior for both.
81b7e54 caused a regression in `SetConsoleWindowInfo` and any other function that used the `WriteToScreen` helper. This is because it assumes that it can place the viewport anywhere randomly and it was written at a time where `TriggerScroll` didn't exist yet (there was no need for that (also not today, but that's being worked on)). Caching the viewport meant that `WriteToScreen`'s call to `TriggerRedraw` would pick up the viewport from the last rendered frame, which would cause the intersection of both to be potentially empty and nothing to be drawn on the screen. This commit reverts 81b7e54 as I found that it has no or negligible impact on performance at this point, likely due to the overall vastly better performance of conhost nowadays. Closes #15932 ## Validation Steps Performed * Scroll the viewport by entire pages worth of content using `SetConsoleWindowInfo` - see #15932 * The screen and scrollbars update immediately ✅ (cherry picked from commit 7a1b6f9) Service-Card-Id: 91152167 Service-Version: 1.19
81b7e54 caused a regression in
SetConsoleWindowInfo
and any otherfunction that used the
WriteToScreen
helper. This is because itassumes that it can place the viewport anywhere randomly and it was
written at a time where
TriggerScroll
didn't exist yet (there wasno need for that (also not today, but that's being worked on)).
Caching the viewport meant that
WriteToScreen
's call toTriggerRedraw
would pick up the viewport from the last renderedframe, which would cause the intersection of both to be potentially
empty and nothing to be drawn on the screen.
This commit reverts 81b7e54 as I found that it has no or negligible
impact on performance at this point, likely due to the overall
vastly better performance of conhost nowadays.
Closes #15932
Validation Steps Performed
SetConsoleWindowInfo
- see Conhost window is not refreshed after software scroll #15932